This invention relates to managing signaling states in packet network telephony gateways and more particularly to handling telephony signaling in a way that minimizes state overhead in the gateway while allowing high scalability.
Packet telephony gateways are sometimes optimized to work in concert with common channel signaling protocols. For example, packet gateways operate with Common Channel Signaling System #7 (CCS#7) or with Integrated Services Digital Network (ISDN) PRI. These protocols allow signal processing entirely outside the gateway itself, such as in a dedicated call control system. This has the advantage of avoiding the need for maintaining any call state in the gateways.
For some types of telephony systems, such as those attached directly to analog telephones or to older trunk systems such as Ear and Mouth (EandM) or Channel Associated Signaling (CAS) systems, the gateway is involved in at least low level telemetry aspects of call signaling. In CAS-like scenarios, the gateway also needs to disentangle the channel associated signaling from truly in-band signaling, such as Dual Tone Multi Frequency (DTMF) signaling.
The types of telemetry signals received by the gateway from a telephone include on-hook and off-hook transitions, hook flash, progress tone detection (and possibly analysis) and DTMF detection and possible generation. For trunks connected via in-band signaling to PBXs, analog switches, etc., a gateway needs to hear various progress signals like busy, network congestion, etc. The gateway then needs to process (i.e. xe2x80x9cprogress tone analysisxe2x80x9d) and convert the signals into events.
The simplest approach is to back-haul telemetry-like signaling to a signaling or call processing server and treat the signaling in the call processing server identically as in the common channel signaling case. Unfortunately, this fails to scale for a couple of reasons. The number of independent signaling channels can be extremely large, possibly on the same order of magnitude as the number of stations on a local carrier""s network. The number of messages generated can also be very large; many more than 2-3 per call as in the common channel signaling case. For example, every digit pressed while dialing a phone number can constitute a message that must be sent to the call process server. The back-haul signaling approach substantially increases network traffic between the gateway and the call processing server and requires additional computing resources to transmit, receive and process the back-hauled signaling.
Thus, a need remains for reducing the overhead required to maintain call states in the gateway while simultaneously providing gateway intelligence that allows the gateway to process telephone events more efficiently.
A signal state management (SSM) system according to the invention avoids both the overhead of maintaining call state and complex signaling in a gateway, while simultaneously providing a more scalable system by not placing too great a state or processing burden on the signaling or call processing server. Besides providing a more scalable system, the SSM system has the ability to create (possibly a dynamic) adaptation based on several varied classifications. Classifications can include user identity, type of service subscribed, time of day, type of gateway, location of telephone instruments within the network, etc. The system manages signaling without adding to the programming complexity, and processing burden of the packet gateway device.
The SSM system sends an event/action table from a call agent to the gateway. The event/action table directs the gateway to detect and accumulate specified signaling events generated by a telephone. The gateway detects and accumulates the signaling events according to the event/action table and notifies the call agent only when certain signaling events specified in the event/action table are detected. The call agent then acknowledges the notification by sending a new event/action table to the gateway that directs the gateway to detect and accumulate a new set of signaling events. The gateway then accumulates signaling events according to the new event/action table and only notifies the call agent when the signaling events specified in the new event/action table are detected.
After notifying the call agent, the gateway operates in a quarantine state where all signaling events generated by the telephone are queued by the gateway. The gateway remains in the quarantine state until the new event/action table is received from the call agent.
The event/action table can include a digit map that directs the gateway to accumulate signaling events into a dial string. The dial string is continuously compared with the digit map. Signaling events are added to the dial string if the current dial string is underqualified and only partially matches the digit map. The dial string is sent in a single message to the call agent current dial string matches a complete entry in the digit map. The event/action table specifies the events that the gateway is to detect such as tones, hook transitions and telephone digits. The event/action table also specifies actions that the gateway takes when the specified events are detected, such as ignore, send immediately and accumulate.